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DESCRIPTION DE CONTENU DE PAQUETS DANS UN RESEAU 
DE COMMUNICATION PAR PAQUETS 



5 L'invention a trait aux reseaux de communication par paquets mettant en 

ceuvre des protocoles organises en couches tels que standardises dans le modele de 
reference OSI (« Open System Interconnection ») defini par ('Organisation 
internationale de normalisation, dit ISO ou pouvant s'y assimiler. Plus 
particulierement, ('invention concerne un procede de fonctionnement d'un noeud 

10 d'un reseau de communication par paquets, en particulier d'un routeur IP. Elle 
concerne aussi un paquet de donnees pour un reseau de communication par paquets 
et un generateur de paquets de donnees pour un reseau de communication par. 
paquets. 

(.'optimisation de la transmission des paquets emis dans un reseau de 
15 communication par paquets tel qu'un reseau au protocole IP (de I'anglais « Internet 
Protocol ») repose sur le traitement specifique des paquets au niveau des noeuds du 
reseau en fonction de leur contenu. Dans le cas d'un reseau au protocole IP, les 
noeuds sont traditionnellement appeles routeurs. 

En particulier, les mecanismes de qualite de sen/ice ou QoS dans les reseaux 
20 comprennent un traitement differencie de paquets emis sur le reseau, en fonction de 
parametres tels que I'expediteur, le destinataire ou le type de donnees contenu dans 
le paquet. Les noeuds du reseau traitent les paquets en fonction de ces parametres, 
par exemple en leur attribuant un routage, une bande passante, une priorite, ou 
toute autre caracteristique adequate. La qualite de service est en particulier 
25 primordiale pour garantir une transmission dans de bonnes conditions de paquets 
contenant de la voix ou de la video, notamment dans le cas de voix sur IP ou de 
video sur IP. 

II est done necessaire de pouvoir determiner ces parametres pour gerer 
correctement et efficacement les flux de paquets. • 
30 II existe des logiciels tels que PacketShaper™ de la societe americaine 

Packeter, Inc. ou des processeurs tels que Content Processor 5000™ de la societe 
americaine LeWiz Communications, Inc prevus pour etre mis en oeuvre dans les 
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routeurs et qui realisent une estimation du type de donn6es contenues dans un 
paquet. Le routeur realise cette estimation du type de donnees contenues dans le 
paquet en examinant les paquets pour determiner les protocoles utilises dans la 
partie des paquets correspondent aux couches OSI 5 a 7 (e'est-a-dire les couches 5 a 
5 7 du modele de reference OSI). Le routeur peut notamment determiner que le 
protocole utilise est FTP (de I'anglais « File Transfer Protocol ») ou HTTP (de I'anglais 
« Hypertext Transfer Protocol »). Ensuite, le routeur examine eventuellement les autres 
parties du paquet pour determiner le type de donnees contenues dans le paquet, par 
exemple par reconnaissance de la signature d'une application ou d'un type de 
10 donnees presente parmi les donnees dans le corps du paquet (appele « paylaod »). 
Le routeur suppose que le paquet appartient a une categorie de traitement predefinie 
en fonction du protocole reconnu ainsi que de I'eventuelle signature reconnue. Le 
paquet est ensuite classe dans la categorie predefinie, et le routeur lui applique les 
traitements correspondents a cette categorie. 
15 Ce procede presente cependant des inconvenients. D'une part, lors de 

I'utilisation d'un nouveau protocole dans les couches OSI 5 a 7 d'un paquet, le 
protocole n'est pas reconnu par un routeur non mis a jour. Le routeur ne peut done 
plus supposer le contenu d'un tel paquet de donnees. Le routeur ne peut alors plus 
realiser une gestion de la qualite de service en fonction du contenu d'un paquet. 
20 D'autre part, un meme protocole peut etre utilise pour des types de donnees 
differentes. Par exemple, le protocole HTTP est utilise a la fois pour le transport de 
contenus interactifs et pour le transfert de fichiers statiques, et ne permet de 
transporter des informations que sur les donnees qui sont transportees dans une 
sequence de paquets (typiquement un flux TCP) et pas par un paquet seul. Ainsi, le 
25 routeur ne peut pas determiner precisement le type de donnees uniquement en 
fonction du protocole de transmission utilise. Par ailleurs, il n'est pas possible de 
programmer le routeur pour reconnoitre de fagon exhaustive les signatures de toutes 
les applications ou de tout type de donnees qui peuvent etre presentes dans le 
paquet. De plus, il se pose le probleme de la mise a jour des routeurs avec les 
30 signatures de nouvelles applications ou de donnees a un nouveau format. Le routeur 
n'est done pas toujours capable de reconnoitre correctement le type de donnees 
contenues dans les paquets. La qualite de service n'est aiors pas optimale car les 
differents types de donnees peuvent requerir des exigences techniques differentes. 
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Une autre possibility pour fournir les parametres utiles aux routeurs 
consisterait a utiliser un protocole de signalisation connu qui soit prevu pour fournir 
des informations de ce type. Ainsi, il est envisageable de recourir au protocole SIP (de 
1'anglais « Session Initiation Protocol ») qui permet d'envoyer des messages contenant 
5 le type de donnees transports dans un flux de paquets. Neanmoins, cette solution 
presente des inconvenients car les messages sont emis d'un element reseau emetteur 
vers un element reseau destinataire et ne sont pas congu pour faciliter leur 
interpretation par les routeurs. En particulier, ils sont transports dans une sequence 
de paquets qui doivent etre le cas echeant re-ordonnances avant de pouvoir 

10 interpreter leur contenu. De plus, le protocole de signalisation 6tant different du 
protocole de transmission des paquets de donnees decrits, la probability que le 
message et les paquets de donnees empruntent des trajets differents est extremement 
elevee. Ainsi, les routeurs empruntes par les paquets de donnees ne disposent pour 
la plupart pas de la description contenue dans le message. Ces routeurs ne peuvent • 

1 5 done pas gerer de fagon optimale la transmission des paquets de donnees. 

II existe done un besoin pour un procede de transmission qui resolve un ou 
plusieurs des inconvenients cites auparavant. 

L'invention a ainsi pour objet un procede de fonctionnement d'un noeud 
d'un reseau de communication par paquets, en particulier d'un routeur IP, 

20 comprenant les etapes de : 

a) reception par le naaud d'un paquet depuis le reseau ; 

b) reception par le noeud d'une information independante des protocoles 
des couches OSI 5 a 7 du paquet et concernant au moins I'une des caracteristiques 
suivantes : 

25 - le type de donnees transportees dans le paquet, 

- la source d'emission des donnees transportees dans le paquet 
autre que I'adresse reseau de la source d'emission du paquet, et 

- le destinataire des donnees transportees dans le paquet autre que 
I'adresse reseau de la source d'emission du paquet ; 

30 c) traitement du paquet par le noeud en fonction de ladite description. 

II est plus avantageux encore que ^information regue dans I'etape b) soit 
independante des protocoles des couches OSI 4 a 7 du paquet. 
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Selon un mode de realisation prefere, ladite information est contenue dans 
le paquet, I'etape b) comprenant la lecture de ladite information dans le paquet par 
le noeud, Ladite information peut notamment etre contenue dans I'en-tete au 
protocole de la couche OSI 3 du paquet, I'etape b) comprenant alors la lecture par le 
5 noeud de ladite information dans I'en-tete au protocole de la couche OSI 3 du 
paquet. 

Selon un autre mode de realisation prefere, le paquet contient un identifiant 
de ladite information, I'etape a) comprenant la lecture de I'identifiant par le noeud. 
L'identifiant peut notamment etre contenu dans I'en-tete au protocole de la couche 

10 OSI 3 du paquet, I'etape a) comprenant la lecture par le noeud de I'identifiant dans 
I'en-tete au protocole de la couche OSI 3 du paquet. Par ailleurs, il est avantageux 
que I'etape b) comprenne la reception par le noeud d'un autre paquet depuis le 
reseau, ledit autre paquet contenant ladite information. Ladite information peut 
notamment etre contenue dans I'en-tete au protocole de la couche OSI 3 dudit autre 

15 paquet, I'etape b) comprenant alors la lecture par le noeud de ladite information 
dans I'en-tete au protocole de la couche OSI 3 dudit autre paquet. En variante, 
Procede selon ladite information peut etre contenue dans le corps selon le protocole 
de la couche OSI 3 dudit autre paquet, I'etape b) comprenant alors la lecture par le 
noeud de ladite information dans le corps selon le protocole de la couche OSI 3 dudit 

20 autre paquet. II est avantageux que ledit autre paquet contienne en outre I'identifiant, 
I'etape b) comprenant egalement la lecture par le noeud de I'identifiant dans ledit 
autre paquet. L'identifiant peut notamment etre contenu dans I'en-tete au protocole 
de la couche OSI 3 dudit autre paquet auquel cas I'etape b) comprend la lecture par 
le noeud de l'identifiant dans I'en-tete au protocole de la couche OSI 3 dudit autre 

25 paquet. Le procede peut encore avantageusement comprendre apres I'etape b), une 
etape d'envoi par le noeud vers une base de donnees, de l'identifiant et de ladite 
information. 

Selon un autre mode de realisation prefere, le procede comprend apres 
I'etape a) et avant I'etape b), une etape d'interrogation par le noeud d'une base de 
30 donnees avec I'identifiant. 

Selon un autre aspect, I'invention propose aussi un paquet de donnees pour 
un reseau de communication par paquets, comprenant une information 
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independante des protocoles des couches OSI 5 a 7 du paquet et concernant au 
moins I'une des caracteristiques suivantes : 

- le type de donnees transportees dans le paquet, 

- la source d'emission des donnees transportees dans le paquet autre que 
5 I'adresse reseau de la source d'emission du paquet, et 

- le destinataire des donnees- transportees dans le paquet autre que 
I'adresse reseau de la source d'emission du paquet. 

II est plus avantageux encore que ladite information soit independante des 
protocoles des couches OSI 4 a 7 du paquet. 
10 Selon un mode de realisation prefere, ladite information est contenue dans 

I'en-tete au protocole de la couche OSI 3 du paquet. De fagon preferentielle, le 
paquet est au protocole IP, ladite information etant contenue dans I'en-tete IP. 

Selon un autre aspect encore, I'invention propose un generateur de paquets 
selon I'invention tels que definis precedemment. 
1 5 D'autres caracteristiques et avantages de I'invention apparaitront a la lecture 

de la description qui suit de modes de realisation de I'invention, donnee a titre 
d'exemple et en reference aux dessins annexes qui montrent : 

-figure 1, une representation schematique d'un exemple de reseau de 
transmission dans lequel I'invention est mise en oeuvre ; 
20 -figure 2, une structure d'un paquet de donnees contenant une description 

de donnees ; 

-figure 3, une structure d'un paquet de donnees contenant un identifiant de 
description de donnees ; 

-figure 4a, une structure d'un paquet de donnees contenant a la fois un 
25 identifiant de donnees et une description de donnees dans I'entete du 

paquet ; 

-figure 4b, une structure d'un paquet de donnees contenant un identifiant de 
description de donnees placee dans I'en-tete du paquet et une description 
de donnees placee dans le corps du paquet ; 
30 -figure 5, une structure d'un paquet de donnees contenant une description 

de donnees dans le corps du paquet. 

Selon I'invention, le procede de fonctionnement d'un nceud d'un reseau de 
communication par paquets, comprend les etapes de : 
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a) reception par le noeud d'un paquet depuis le r6seau ; 

b) reception par le noeud d'une information independante des protocoles 
des couches OSI 5 a 7 du paquet et concernant au moins I'une des caracteristiques 
suivantes : 

5 le type de donnees transportees dans le paquet, 

la source d'emission des donnees transportees dans le paquet 
autre que I'adresse reseau de la source d'emission du paquet, 
et 

le destinataire des donnees transportees dans le paquet autre 
10 que I'adresse reseau de la source d'emission du paquet ; 

c) traitement du paquet par le noeud en fonction de ladite description. 

L'on comprendra que I'ordre dans le temps des etapes a) et b) est 
indifferent. Autrement dit, I'etape a) peut etre posterieure ou anterieure a I'etape b). 
Les etapes a) et b) peuvent egalement etre concomitante notamment dans le cas ou 
1 5 ladite information est contenue dans le paquet lui-meme. 

L'on comprendra que ladite information peut concerner uniquement I'une 
quelconque des caracteristiques indiquees dans I'etape b), ou deux quelconques 
d'entre elles ou encore les trois. Elles peut encore comporter d'autres informations 
concernant par exemple le traitement a effectuer par le noeud sur les paquets. 
20 Le fait que ladite information est fournie au noeud permet done a ce dernier 

de traiter le paquet - par exemple de choisir un chemin dans le reseau - en fonction 
de ladite information. Autrement dit, le traitement du paquet ne depend plus 
seulement des informations contenues conventionnellement dans le paquet a cette fin 
telles que I'adresse reseau de la source du paquet et I'adresse reseau du destinataire 
25 final du paquet. 

Du fait que ladite information est independante des protocoles des couches 
OSI 5 a 7 utilises dans le paquet, le noeud peut lire et comprendre ladite information 
sans connaTtre ces protocoles. Autrement dit, le noeud est capable de traiter le paquet 
en fonction de ladite information sans connaTtre les protocoles des couches 5 a 7. II 
30 est encore plus avantageux que ladite information soit independante du protocole de 
la couche OSI 4 utilise dans le paquet, ce qui permet au noeud de traiter le paquet en 
fonction de ces informations independamment de ce protocole. En effet, un noeud de 
reseau peut ne pas etre capable d'analyser la couche correspondante des paquets 
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qu'il regoit pu encore il n'est pas souhaitable qu'il doive pouvoir le faire pour des 
raisons de vitesse de traitement. 

Ladite information est avantageusement ecrite selon un code ou langage 
que le noeud est capable de comprendre. Ce code ou langage peut toujours etre le 
5 meme quel que soit le paquet concerne. 

De fagon preferee, ladite information peut etre incluse dans la paquet lui- 
meme. Ceci permet de faire parvenir de fagon simple et fiable ladite information au 
noeud du reseau pour traiter le paquet de donnees correspondent. II est avantageux 
que ladite information soit completement contenue dans le paquet concerne par 

10 ('information car il 'agit d'une maniere simple d'assurer que le nceud regoive toujours 
ladite information pour chacun des paquets. Si, au contraire, ladite information etait 
repartie dans plusieurs paquets, le noeud doit la reconstituer a partir de la pluralite 
de paquets en les ordonnangant de fagon adequate, ce qui rend ('operation plus 
complexe. De plus, le noeud peut etre dans I'impossibilite de reconstituer 

1 5 ('information s'il ne regoit pas I'un d'entre eux par exemple en cas de changement de 
chemin de routage dans le reseau. 

Etant donn6e que les donnees envoyees d'un terminal emetteur vers un 
terminal destinataire dans un reseau sont generalement transportees dans un flux 
constitues de nombreux paquets contenant chacun le meme type de donnees par 

20 exemple audio, chaque paquet peut simplement contenir - au lieu de ladite 
information - un identifiant de ladite information, I'identifiant etant independant des 
protocoles des couches OSI 5 6 7, voire des couches OSI 4 a 7, utilises dans le 
paquet. Le noeud determine alors ladite information qui correspond a I'identifiant 
pour traiter chaque paquet en fonction de ladite information. Ladite information peut 

25 etre fourni au noeud par differents moyens telles que par un paquet qui la contient ou 
par une base de donnee qu'il interroge. 

L'invention est particulierement adaptee a etre mise en oeuvre dans un 
reseau au protocole IP (qui correspond a la couche OSI 3). On rappelle qu'un reseau 
IP est organise typiquement en quatre couches : la couche Internet au protocole IP 

30 correspondent a la couche OSI 3, la couche transport (typiquement au protocole TCP 
ou UDP) correspondent a la couche OSI 4, et la couche application correspondent 
aux couches OSI 5 a 7. 
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La figure 1 represente schematiquement un exemple de r6seau de 
communication par paquets 1, en ('occurrence un reseau au protocole IP. Le reseau 

I comprend un terminal 2 envoyant des paquets de donnees par I'intermediaire d'un 
sous-reseau 3 vers un destinataire final non represente. On designera dans la suite 

5 par donnees utiles d'un paquet les donnees transportees dans ce paquet qui sont a 
transmettre au destinataire final du paquet soit en I'etat, soit eventuellement sous 
forme modifiee (dans le cas de traitement effectue par le reseau sur les donnees 
transportees). 

Le sous-reseau 3 est muni de routeurs 4 a 7 fournissant plusieurs trajets de 
10 routage aux paquets de donnees a travers le sous-reseau 3. 

Le terminal 2 comprend un generateur 8 de paquets de donnees pouvant 
etre d'un type quelconque connu, par exemple une application logicielie de 
transmission de voix ou de video sur IP. Le generateur 8 genere des paquets. de 
donnees au protocole IP qui sont envoyes vers le destinataire final a travers le sous- 
15 reseau 3 grace a une interface 9 adequate du terminal 2. 

Pour assurer un traitement correct d'un paquet emis par le generateur 8, il 
est souhaitable que le routeur qui regoit ce paquet puisse connaitre des informations 
concernant les donnees utiles transportees, leur source ou leur destinataire. Dans ce 
but, I'on fait par/enir au routeur des informations a ce sujet pour lui permettre de 
20 traiter le paquet de fagon adequate. Pour la suite, nous prendrons en exemple la 
fourniture au routeur d'informations concernant les donnees transportees que Ton 
designera par commodite de description de donnees. 

Selon un premier mode de realisation, cette description de donnees est 
placee dans le paquet transportant ces donnees. Plus particulierement, il est 
25 avantageux que la description de donnees soit placee dans I'en-tete IP de ce paquet 
comme illustre par la figure 2. 

La figure 2 represente la structure d'un paquet 10 comprenant un en-tete IP 

II et un corps 1 2 (aussi communement appele « payload » en anglais). L'en-tete 1 1 
comprend une description 13 des donnees utiles contenues dans le corps 12 du 

30 paquet. Le corps 1 2 contient les donnees utiles a transmettre au destinataire final du 
paquet et qui peuvent etre au format d'un protocole d'une couche OSI superieure a 
la couche IP, ce dernier etant un protocole correspondent a la couche OSI 3. En 
particulier, le corps 1 2 peut classiquement contenir un en-tete a un protocole 
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correspondent a la couche OSI 4 (elite couche transport) tel que TCP (de I'anglais 
« Transmission Control Protocol ») ou UDP (de I'anglais « User Datagram Protocol ») 
encapsulant les donnees utiles a transmettre au destinataire du paquet. Les donnees 
sont au format d'un protocole de la couche application du modele IP qui correspond 
5 aux couches OSI 5 a 7 comme mentionne plus haut. Ces donnees peuvent par 
exemple etre de la voix sur IP ou de la video sur IP. 

Les routeurs 4 a 7 sont prevus pour lire la description de donnees 13 placee 
dans I'en-tete IP 1 1 des paquets qu'ils regoivent et traiter chaque paquet en fonction 
de la description 1 3 contenue dans son en-tete IP. 
1 0 Le fait que la description de donnees 1 3 soit placee dans I'en-tete IP du 

paquet 10 est avantageuse puisque le routeur peut la lire en analysant uniquement 
I'en-tete IP VI du paquet. Or, un routeur est classiquement capable d'analyser les 
en-tetes IP. Au contraire, il n'a pas besoin de traiter le corps 12 du paquet. Ainsi, le 
routeur n'a pas besoin de connaTtre le ou les protocoles des couches OSI 4 6 7 qui 
1 5 sont eventuellement utilisees dans le corps 1 2 du paquet. Par consequent, I'on evite 
que le routeur ait a faire des traitements sur les donnees dans le corps 1 2 du paquet 
et en pariiculier sur les donnees utiles transportees, le routeur n'etant pas destine a 
effectuer ce type de traitement. D'autre part, le routeur est en mesure de traiter la 
description de donnees 13 quel que soient le ou les protocoles des couches OSI 4 a 7 
20 utilises dans le corps 12 du paquet. Enfin, la description 13 complete etant contenue 
dans le paquet a traiter, le routeur n'a pas besoin de reconstituer preaiablement la 
description en lisant plusieurs paquets differents qu'il reordonnance avant de pouvoir 
traiter un paquet en fonction de la description de donnees. 

Ce mode de realisation est particulierement adapte a etre mis en oeuvre 
25 avec les paquets au protocole IPv6 car un tel paquet presente une en-tete 1 1 de faille 
suffisante pour inclure une description de donnee. Dans ce cas, la description de 
donnees 13 peut notamment etre placee dans une extension d'en-tete (appelee 
« extension header » en anglais) de I'en-tete IPv6, par exemple une extension d'en- 
tete du type dit « Hop-by-Hop Options ». 
30 Mais ce mode de realisation peut egalement etre mis en oeuvre avec les 

paquets au protocole IPv4 par exempje en inscrivant la description de donnees 1 3 
dans une option de I'en-tete 1 1 . 
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Par ailleurs, il est avantageux d'avoir une information dans I'en-tete 1 1 du 
paquet indiquant au routeur le fait qu'il contient une description de donnees. II peut 
notamment s'agir d'un marqueur predetermine dans I'en-tete IP. Sous IPv6, dans le 
cas cite ou la description de donnees 13 est placee dans une extension d'en-tete, il 
5 peut par exemple s'agir d'un code predetermine place dans I'extension d'en-tete 
immediatement a la suite de son propre en-tete. Sous IPv4, dans le cas cite ou la 
description de donnees 13 est placee dans une option d'en-tete, il peut notamment 
s'agir de I'octet codant le type d'option. 

Concernant les traitements a effectuer par un routeur donne en fonction de 
1 0 la description de donnees 1 3, le routeur peut etre configure par un gestionnaire de 
routage 20 (appele en anglais « Policy Decision Point » ou PDP) par exemple via le 
reseau IP lui-rneme. 

Bien entendu, dans le cas d'un routeur non prevu pour interpreter la 
description de donnees 13, il peut se borner a traiter - en particulier router - le 
1 5 paquet 1 0 de fagon conventionnelle sans tenir compte de la description 1 3. 

Dans ce premier mode de realisation, chaque paquet 10 est traite par les 
routeurs en fonction de la description de donnees 13 qui est placee dans ce paquet. 

Selon un deuxieme mode de realisation, un identifiant de la description de 
donnees est placee dans le paquet IP envoye par le terminal 2. Plus precisement, a 
20 un identifiant place dans un paquet de donnees correspond une description des 
donnees utiles transportees dans le paquet contenant cet identifiant. L6-encore, 
['identifiant peut avantageusement etre inclus dans I'en-tete IP du paquet. La figure 3 
illustre la structure d'un tel paquet 10a avec un identifiant 14 de la description de 
donnees qui est placee dans I'en-tete IP 1 1, le corps (ou « payload ») du paquet etant 
25 referenced. 

Sous IPv6 ou IPv4, I'identifiant peut par exemple etre placee dans une 
extension d'en-tete ou une option respectivement de fagon similaire a celle decrite 
pour la description de donnees 13 dans le premier mode de realisation. 

Par ailleurs, tl est avantageux d'avoir une information dans I'en-tete 1 1 du 
30 paquet indiquant au routeur le fait qu'il contient un identifiant 14. Sous IPv4 ou IPv6, 
cela peut etre mis en ceuvre de fagon similaire aux exemples donnees pour 
('indication de la presence de la description de donnees 13 dans le premier mode de 
realisation. 
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Les routeurs 4 a 7 peuvent etre prevus pour lire I'identifiant 14 dans I'en- 
tetes IP 1 1 des paquets qu'ils regoivent et determiner la description de donnees qui 
correspond a I'identifiant 14 . Ensuite, le routeur traite le paquet en fonction de la 
description de donnees correspondante a I'identifiant 1 4 contenu dans son en-tete IP 
5 11. 

Ce mode de realisation est avantageux par rapport au precedent dans la 
mesure ou la faille de I'identifiant 14 peut etre moindre en cornparaison de la 
description de donnees, ce qui laisse done plus de place disponibles dans les paquets 
pour les donnees utiles a transporter. 

10 .'I existe differente maniere de mettre a disposition d'un routeur la 

description de donnees correspondent a un identifiant 14. 

Une maniere avantageuse consiste a envoyer sur le reseau un paquet IP 
contenant a la fois I'identifiant 14 et la description de donnees correspondent a 
I'identifiant 14. Ce paquet est preferentiellement envoye le long du chemin a trovers 

15 le reseau qui sera emprunte subsequemment par les paquets 10a contenant 
I'identifiant 14 sans la description de donnees. Ainsi, la description de donnees est 
mise a la disposition des routeurs concernes par ce flux de paquets. II peut par 
exemple s'agir d'un paquet envoye par le terminal 2 vers le destinataire final qui 
contient done a la fois I'identifiant 14 et la description de donnees. 

20 L a figure 4a illustre un exemple de structure d'un tel paquet, reference 15a, 

dans lequel I'identifiant 14 et la description de donnees 13 correspondent a 
I'identifiant 14 sont tous les deux places dans I'en-tete IP du paquet 15a. Le corps 12 
du paquet peut contenir des donnees utiles. Sous IPv6, I'identifiant 14 peut par 
exemple etre placee dans une extension d'en-tete et la description 13 dans une autre 

25 extension d'en-tete. En variante, I'identifiant 14 et la description 13 peuvent etre 
placee dans une meme extension d'entete. Sous IPv4, I'identifiant 14 peut par 
exemple etre placee dans une option d'en-tete et la description 13 dans une autre 
option d'en-tete. En variante, I'identifiant 14 et la description 13 peuvent etre placee 
dans une meme option d'entete. 

30 La fi 9 ure 4b illustre un autre exemple de structure d'un tel paquet, reference 

15b, dans lequel I'identifiant 14 est place dans I'en-tete IP 1 1 et la description de 
donnees 13 correspondent a I'identifiant 14 est placee dans le corps 12 du paquet. 
Le reste de place disponible dans le corps 12 du paquet peut contenir des donnees 
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utiles. Sous IPv6, I'identifiant 14 peut par exemple etre place dans une extension 
d'en-tete. La description 13 peut etre placee a un endroit predetermine dans le corps 
12 du paquet. Sous IPv4, I'identifiant 14 peut par exemple etre placee dans une 
option d'en-tete. La description 13 peut aussi etre placee a un endroit predetermine 
5 dans le corps 12 du paquet. La structure de paquet de la figure 4b est 
particulierement adaptee au cas ou la taille de la description 13 est trop importante 
pour etre contenue dans I'en-tete IP 1 1 . 

Par ailleurs, il est avantageux d'avoir une information dans I'en-tete 1 1 du 
paquet indiquant au routeur le fait qu'il contient a la fois un identifiant 14 et une 

1 0 description 1 3. Sous IPv4 ou IPv6, cela peut etre mis en ceuvre de fagon similaire aux 
exemples donnees pour Vindication de la presence de la description de donnees 1 3 
dans le premier mode de realisation. 

Lorsque le routeur recoit un tel paquet contenant a la fois I'identifiant 14 et 
la description 15, il lit ces derniers. Le routeur peut alors traiter ce paquet 15 en 

15 fonction de la description 13. Par ailleurs, le routeur garde en memoire I'identifiant 
14 et la description 13 correspondante. Ainsi, lorsque le routeur recoit 
subsequemment des paquets de type 10a contenant I'identifiant 14, il traite ces 
paquets en fonction de la description 13 correspondent a I'identifiant 14 
precedemment memorises. 

20 Dans le cas ou la mise a disposition des routeurs la description de donnees 

correspondent a un identifiant se fait par I'envoi d'un paquet IP contenant d la fois 
I'identifiant 14 et la description de donnees 13 correspondante, il est preferable 
d'assurer que ce paquet emprunte le meme chemin d trovers le reseau que les 
paquets subsequents incluant I'identifiant 14. Ainsi, tous les routeurs sur le chemin 

25 des paquets subsequents auront eu la possibility de memoriser au prealable la 
description 13. En particulier, les routeurs peuvent etre prevus pour appliquer le 
meme routage 6 tous les paquets comportant un meme identifiant 14, qu'il 
comprenne en outre la description 13 ou non. En variante, sous IPv6, tous les 
paquets de ce flux de paquets sont affectes d'un meme « Flow Label » et les routeurs 

30 sont prevus pour appliquer toujours le meme routage a tout paquet presentant un 
meme « Flow Label ». 

Un paquet contenant d la fois I'identifiant 14 et la description 13 peut etre 
envoye une seule fois prealablement aux autres paquets du flux du type 10a incluant 
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I'identifiant 14 sans la description 13. Mais il est plus avantageux d'envoyer un 
paquet contenant a la fois I'identifiant 14 et la description 13 regulierement, par 
exemple a cheque fois apres qu'un certain nombre de paquets du type 10a ont ete 
envoyes. Ainsi, un routeur qui a accidentellement perdu de sa memoire le descriptif 
5 de donnees 13 correspondent a I'identifiant 14 peut le remettre en memoire. De 
preference, le routeur met a jour sa memoire avec la description de donnee 13 pour 
I'identifiant 14 concerne a chaque fois qu'il regoit un tel paquet. 

II peut en outre etre prevu que le routeur n'utilise la description 1 3 qu'il a en 
memoire pour un identifiant 14 donne que pendant une duree predetermine depuis 

10 la reception du dernier paquet contenant a la fois cet identifiant 14 et cette 
description 13. Cette duree d'expiration est preferentiellement definie pour etre 
superieure au temps separant un paquet contenant a la fois I'identifiant 14 et la 
description 13 du prochain paquet contenant egalement a la fois I'identifiant 14 et la 
description 1 3 pour un meme flux de paquets. De la sorte, il est inutile de gerer la fin 

1 5 du flux de paquets - presentant tous I'identifiant 1 4 - envoyes par le terminal 2 pour 
pouvoir eventuellement reaffecter ulterieurement I'identifiant a une autre description 
de donnees 13. 

Concernant le deuxieme mode de realisation, une autre possibility de mettre 
a la disposition d'un routeur la description de donnees 13 correspondent a un 

20 identifiant 14 consiste a donner acces au routeur a une base de donnees 21 qui 
stocke les identifiants 14 et les descriptions de donnees 13 correspondantes. La 
communication entre le routeur et la base de donnees 21 peut etre assuree via le 
reseau IP lui-meme comme illustre sur la figure 1 . Bien entendu, la meme base de 
donnees 21 peut etre avantageusement accessible a une pluralite de routeurs, voire a 

25 I'ensemble des routeurs du sous-reseau 3. 

Ainsi, lorsqu'il regoit un paquet 10a, le routeur lit I'identifiant 14 contenu 
dans le paquet. II interroge alors la base de donnees 21 avec cet identifiant 14 et la 
base de donnees 21 lui retourne la description de donnees 13 correspondante. Le 
routeur traite ensuite le paquet en fonction de la description de donnees 1 3 fournie 

30 par la base de donnees 21 . En outre, le routeur peut stocker en memoire I'identifiant 
14 et la description 13 correspondante. Dans ce cas, lorsque le routeur regoit 
subsequemment des paquets de type 10a contenant le meme identifiant 14, il traite 
ces paquets en fonction de la description 13 correspondante precedemment 
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memorises. Autrement dit, le routeur verifie s'il n'a pas deja en memoirs une 
description 13 associee a I'identifiant 14 lu dans le paquet et interroge la base de 
donnees 21 uniquement si la verification est negative. Par consequent, le traitement 
des paquets subsequents est plus rapide puisqu'il ne perd pas le temps lie a 
5 ^interrogation de la base de donnees 21 . 

Le recours a la base de donnees 21 est avantageuse car un routeur a 
toujours la possibility de connaitre la description 13 pour un identifiant quelconque 
meme si le chemin emprunte par les differents paquets varient ou encore si la 
description 1 3 correspondent a un identifiant 14 est accidentellement effacee dans la 
10 memoire du routeur. 

II existe differentes manieres de mettre a jour la base de donnees 21. Par 
exemple, le terminal 2 peut envoyer un paquet IP contenant a la fois I'identifiant 14 
et la description 1 3 correspondante vers la base de donnees 21 . La base de donnees 
21 en accuse reception au terminal 2 par un message en retour. Apres reception de 
15 I'accuse de reception, le terminal 2 envoie les paquets IP avec les donnees utiles et 
comportant I'identifiant 14 vers le destinataire final. 

Suivant une mise en oeuvre particulierement avantageuse, on combine 
I'utiiisation de la base de donnees 21 et le procede decrit precedemment pour mettre 
a la disposition des routeurs la description de donnees correspondent a un identifiant 
20 14 qui comprend I'envoi sur le reseau d'un paquet IP contenant a la fois I'identifiant 
14 et la description de donnees correspondante. Toute la description faite concernant 
I'envoi d'un paquet contenant a la fois un identifiant 14 et la description de donnees 
13 correspondante pour mettre a disposition des routeurs ladite description 13 est 
applicable ici avec les explications complementaires suivantes. 
25 Lorsqu'un routeur regoit un tel paquet contenant a la fois I'identifiant 14 et 

la description 13 correspondante, il lit ces derniers. Le routeur envoie a la base de 
donnees 21 I'identifiant 14 et la description 13, ce qui assure la mise a jour de la 
base de donnees 21. Par ailleurs, le routeur traite ce paquet en fonction de la 
description 13. Enfin, le routeur peut avantageusement garder en memoire 
30 I'identifiant 14 et la description 13 correspondante. Ainsi, lorsque le routeur regoit 
subsequemment des paquets de type 10a contenant I'identifiant 14, il traite ces 
paquets en fonction de la description 13 correspondent a I'identifiant 14 
precedemment memorises. 
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Mais il peut arriver qu'un routeur n'ait pas en memoire la description 13 
correspondent a un identifiant 14 contenu dans un paquet de type 10a. Ce peut etre 
le cas du fait que le routeur I'a perdu accidentellement de sa memoire ou encore 
parce qu'il n'a pas re$u le paquet contenant a la fois ('identifiant 14 et la description 
5 13 correspondante. Cette derniere situation peut notamment survenir lorsque les 
routeurs ont change le cherinin de routage posterieurement a I'envoi du paquet 
contenant a la fois I'identifiant 14 et la description 13 correspondante. Dans ce cas, 
le routeur interroge la base de donnees 21 avec I'identifiant 14. La base de donnees 
21 lui fournit en reponse la description 13 correspondante. Le routeur traite alors le 

1 0 paquet en fonction de la description 1 3 fournie et la memorise pour le traitement des 
paquets regus subsequemment et presentant le meme identifiant 14. 

Bien entendu, similairement au premier mode de realisation, un routeur 
peut etre configure par un gestionnaire de routage 20 (appele en anglais « Policy 
Decision Point » ou PDP), par exemple via le reseau IP lui-meme, pour definir les 

1 5 traitements a effectuer sur un paquet 10a par le routeur en fonction de la description 
de donnees 13 qui y correspond. La base de donnees 21 peut eventuellement faire 
partie du gestionnaire de routage 20. 

Par ailleurs, dans le cas d'un routeur non prevu pour lire les identifiants 14, 
il peut se borner a traiter - en particulier router - le paquet 10a de fagon 

20 conventionnelle sans tenir compte de I'identifiant 14 et de la description 13 
correspondante. 

Dans le cas ou il n'est pas prevu un controle centralise de la definition des 
identifiants 14 dans le reseau, il est possible qu'un meme identifiant 14 soit utilise 
simultanement dans le reseau mais pour des descriptions 13 differentes. Pour eviter 
25 la confusion, les routeurs peuvent prendre en compte des parametres 
supplementaires pour distinguer les flux de paquets, par exemple, I'adresse IP de la 
source des paquets. 

Quel que soit le mode de realisation considere, les descriptions de donnees 
13 et/ou les identifiants 14 peuvent etre places dans les paquets IP envoyes par le 
30 terminal 2 par le terminal 2 lui-meme. Dans ce but, le terminal 2 peut comprendre 
une application logicielle cooperant gvec le generateur de paquets 8 pour y placer la 
description 13 et/ou I'identifiant 14 en fonction du type de paquet a generer. Ce peut 
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aussi etre est le generateur de paquets 8 qui place la description 13 et/ou I'identifiant 
14 dans les paquets IP. 

En variante, c'est le premier routeur auquel est connects le terminal 2 - en 
I'occurrence le routeur 4 - qui ajoute dans les paquets IP provenant du terminal 2 la 
5 description 13 et/ou I'identifiant 14 en fonction du type de paquet a generer. Dans 
ce cas, la description 13 peut etre fournie au premier routeur par le terminal 2 et le 
routeur defini un identifiant 14 qu'il fait correspondre a la description. 

Quel que soit le mode de realisation considere, la description de donnees 
13 peut avantageusement definir le type des donnees utiles transportees dans le 

1 0 paquet ou les paquets IP concerned tel que le fait qu'il s'agisse de donnees audio ou 
video, ou plus generalement qu'il s'agit de donnees faisant partie d'un flux de 
donnees temps reel ou d'un flux de donnees de tres grande taille ou encore que ces 
donnees ont un caractere d'envoi cyclique. La description de donnees peut 
egalement comprendre des caracteristiques techniques concernant les donnees telles 

1 5 que par exemple la frequence d'echantillonnage pour des donnees audio. 

Les routeurs pourront alors traiter - en particulier router - les paquets IP non 
seulement en fonction de la seule adresse IP de destination placee dans leur en-tete, 
mais aussi en fonction de la nature des donnees utiles transportees et de ces autres 
caracteristiques techniques. Le routeur peut notamment utiliser I'equipement le plus 

20 adapte pour traiter le type de donnees concerne. Par exemple, le routeur ou les 
equipements connectes a lui peuvent utiliser I'algorithme le plus adequat pour 
evaluer la qualite de service fournie a I'utilisateur finale pour le flux audio concerne. 
Par exemple, le routeur peut selectionner une carte specifique de gestion de flux 
audio pour realiser de la compression a la volee et a la demande dans le cas de 

25 donnees audio, ou encore pour fusionner plusieurs flux audio et video lors d'une 
conference sur IP. 

Par ailleurs, la description de donnees 13 peut etre completee - ou 
remplacer - avec des informations concernant la source des donnees ou le 
destinataire des donnees autres que leur adresse IP dans le reseau. A titre d'exemple, 
30 il peut s'agir du nom patronymique ou de la denomination sociale de la source et/ou 
du destinataire. Par consequent, le routeur peut traiter les paquets en tenant compte 
de cette information. En particulier, le routeur peut router les paquets en fonction de 
regies de routage definies pour le destinataire ainsi definie avec la description de 
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donnees 13. Par exemple, il peut preferentiel lament envoyer des paquets transportant 
une image vers une des machines du destinataire qui presente un afficheur adapte 
pour I'afficher, independamment de I'adresse IP de destination specifiee dans I'en- 
tete IP du ou des paquets concernes. 
5 Enfin, la description de donnees 13 peut encore inclure des informations 

concernant le traitement a effectuer par les routeurs traverses, notamment des 
informations relatives a la qualite de service QoS (de I'anglais « Quality of Service ») 
a fournir. Par exemple, une telle information peut etre la bande passante a reserver a 
ces paquets de donnees. II peut encore s'agir de parametres de routage, par 

10 exemple, un chemin de routage preferentiel defini par I'emetteur des donnees, en 
I'occurrence, le terminal 2. 

II est avantageux que les descriptions de donnees 13 places dans les 
paquets IP soient ecrits en XML En effet, une description 13 en XML peut etre 
interpretee par la plupart des routeurs, le schema XML utilise pour la description 

1 5 pouvant etre recherche sur le reseau par exemple a une adresse predeterminee de 
celui-ci. Ce schema peut etre ensuite interprets par le routeur pour construire une 
representation interne des informations contenues dans le document XML. 

A titre d'exemple, un descriptif associe a des donnees du type voix, peut etre 
redige en XML de la fagon suivants : 

20 <fl °w xmlns=«http://www.alcatel.com/Routing/Flow/Voice»> 

<source> 

<user> Durand </user> 
</source> 
< destination > 
25 <user> Dupond </user> 

</destination> 

<sampling> 8kbits </sampling> 
<direction> full-duplex </direction> 
Cette description specifie le contenu de type voix (« Voice »), le nom 
30 patronymique de I'emetteur (« Durand ») et du destinataire (« Dupond »), 
I'echantillonnage (« 8kbits »>) et la direction de I'echange (« full-duplex »). En fonction 
de ces informations, les routeurs sont a meme de realiser un routage adapte, en 
associant aux paquets une taille de memoire tampon suffisante pour absorber les 
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effets de gigues qu'on peut rencontrer dans le reseau, ou bien en choisissant une 
route ou une priorite des paquets en fonction de I'identite des destinataires et 
emetteurs. Les differents champs d'une telle descriptif sont de preference normalises. 

Un identifiant 14 associe a ce descriptif peut par exemple prendre la forme 
5 d'un code alphanumerique tel que « voice ». 

L'on comprendra que les descriptions de donnees peuvent aussi etre ecrites 
sous une forme codee au lieu d'etre proche d'un langage nature! plus directement 
comprehensible par I'homme comme le permet XML 

Bien entendu, la presente invention n'est pas limitee aux exemples et modes 
10 de realisation decrits et represents, mais elle est susceptible de nombreuses 
variantes accessibles a Phomme de Tart. Bien qu'on ait decrit auparavant des paquets 
contenant une description 13 et/ou un identifiant 14, il est bien clair que I'invention 
s'applique egalement a des paquets munis de plusieurs descriptions 13 et/ou 
identifiants 14. 

15 Par ailleurs, les premier et deuxieme modes de realisation de ('invention 

decrits plus haut peuvent etre mis en oeuvre sans que la description de donnees 13 ni 
I'identifiant de description 14 ne soient inscrits dans I'en-tete IP du paquet, ni meme 
que I'en-tete IP contienne une quelconque information indiquant que le paquet 
contienne une description 13 et/ou un identifiant 14. A titre d'exemple, la figure 5 

20 illustre un exemple de mise en oeuvre du premier mode de realisation dans lequel un 
la description 13 est placee dans le corps 12 d'un paquet IP 16 alors que son en-tete 
IP 1 1 est du type conventionnel. En I'occurrence, le corps 12 contient a la fin de celui- 
ci un code d'identification predetermine 16 servant a indiquer a un routeur recevant 
le paquet le fait qu'il contient une description 13. Le corps 12 contient 

25 immediatement avant le code d'identification 16 une valeur 17 indicative de la 
longueur de la description 13 dans le paquet 16. La description 13 est placee dans le 
corps immediatement avant la valeur 17. Le reste du corps 12 contient les donnees 
utiles a transporter. Lorsqu'un routeur regoit un paquet IP, il lui suffit de lire la fin du 
paquet pour verifier la presence du code 12. Dans ('affirmative, il lit ensuite la valeur 

30 1 7. Ensuite, le routeur lit la description 13 contigue a la valeur 1 7 dans le paquet 16 
et delimitee par la longueur definie par la valeur 17. Ensuite, le routeur traite le 
paquet comme decrit precedemment. Bien evidemment, le deuxieme mode de 
realisation peut etre mis en oeuvre de fagon similaire, avec I'identifiant 14 qui vient 
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en rernplacement de la description 13 dans le corps 12. Un code 17 specifique 
predetermine peut etre definie au cas ou le corps 12 contient a la fois la description 
13 et I'identifiant 14. Dans ce cas, le code 17 peut etre precede par une valeur 17 
indicative de la longueur de la description 13 dans le paquet 16, puis une autre 
5 valeur 17a indicative de la longueur de I'identifiant 14 dans le paquet 16, puis de la 
description 13 et enfin de I'identifiant 14. Dans une telle mise en oeuvre du premier 
et du deuxieme mode de realisation, la description 13 et/ou I'identifiant 14 sont ecrits 
dans un langage independent des protocoles des couches OSI 5 a 7. Ainsi, les 
routeurs sont capables de lire la description et I'identifiant 14 quel que soit les 

1 0 protocoles des couches OSI 5 a 7. 

Bien que les differents modes de realisations aient ete decrit pour des 
paquets au protocole IP, I'on comprendra que ('invention peut etre mise en oeuvre 
similairement avec d'autres protocoles de la couche OSI 3 (dite couche reseau). 

La mise en oeuvre de I'invention a I'aide des en-tetes au niveau de la couche 

1 5 OSI 3 est preferee car les noeuds sont classiquement prevus pour router les paquets 
grace a ce protocole. Mais I'invention peut aussi etre mise en oeuvre au niveau des 
en-tetes des protocoles de la couche OSI 4 (dite couche transport) dans le cas ou il 
est possible d'y inscrire la description de donnees 13 et/ou I'identifiant 14 et que les 
nceuds ont la capacite de traiter ce protocole ou ces protocoles s'il y en a plusieurs 

20 utilisees au sein du meme reseau. 

Concernant la mise en oeuvre du protocole IPv4, I'on peut se reporter 
notamment au document RFC 791 . 

Concernant la mise en oeuvre du protocole IPv6, I'on peut se reporter 
notamment au document RFC 2460. 

25 Concernant le modele de reference OSI, I'on peut se reporter notamment a 

la norme ISO 7498. 
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REVINDICATIONS 

1 . Precede de fonctionnement d'un noeud d'un reseau de communication par 
paquets, en particulier d'un routeur IP, comprenant les etapes de : 

5 a) reception par le noeud d'un paquet (10; 1 0a) depuis le reseau ; 

b) reception par le noeud d'une information (13) independante des 
protocoles des couches OSI 5 a 7 du paquet et concernant au moins I'une 
des caracteristiques suivantes : 

- le type de donnees transportees dans le paquet, 

10 - ' a source d'emission des donnees transportees dans le paquet autre que 

I'adresse reseau de la source demission du paquet, et 

- le destinataire des donnees transportees dans le paquet autre que 
I'adresse reseau de la source d'emission du paquet ; 

c) traitement du paquet (10 ; 10a) par le noeud en fonction de ladite 
15 description. 

2, Procede selon la revendication 1, caracterise en ce que ('information regue 
dans I'etape b) est independante des protocoles des couches OSI 4 a 7 du 
paquet. 



Procede selon la revendication 1 ou 2, caracterise en ce que ladite 
information (1 3) est contenue dans le paquet (10), I'etape b) comprenant la 
lecture de ladite information dans le paquet par le noeud. 

Procede selon la revendication 3, caracterise en ce que ladite information 
(13) est contenue dans I'en-tete (11) au protocole de la couche OSI 3 du 
paquet (10), I'etape b) comprenant la lecture par le noeud de ladite 
information dans I'en-tete au protocole de la couche OSI 3 du paquet. 

Procede selon la revendication 1 ou 2, caracterise en ce que le paquet (10a) 
contient un identifiant (14) de ladite information, I'etape a) comprenant la 
lecture de I'identifiant par le noeud. 
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6. Procede selon la revendication 5, caracterise en ce que I'identifiant (1 4) est 

contenu dans I'en-tete (1 1) au protocole de la couche OSI 3 du paquet 
(10a), I'etape a) comprenant la lecture par le nceud de I'identifiant dans 
I'en-tete au protocole de la couche OSI 3 du paquet. 

5 7. Precede selon la revendication 5-ou 6, caracterise en ce que I'etape b) 

comprend la reception par le nceud d'un autre paquet (1 5a ; 1 5b) depuis le 
reseau, ledit autre paquet contenant ladite information (13). 

8. Procede selon la revendication 7, caracterise en ce que ladite information 
(13) est contenue dans I'en-tete (1 1) au protocole de la couche OSI 3 dudit 

1 0 autre paquet (1 5a), I'etape b) comprenant la lecture par le nceud de ladite 

information dans I'en-tete au protocole de la couche OSI 3 dudit autre 
paquet. 

9. Procede selon la revendication 7, caracterise en ce que ladite information 
(13) est contenue dans le corps (1 2) selon le protocole de la couche OSI 3 

1 5 dudit autre paquet (1 5b), I'etape b) comprenant la lecture par le nceud de 

ladite information dans le corps selon le protocole de la couche OSI 3 dudit 
autre paquet. 

10. Procede selon la revendication 7, 8 ou 9, caracterise en ce que ledit autre 
paquet (1 5a ;1 5b) contient en outre I'identifiant (14), I'etape b) comprenant 

20 la lecture par le nceud de I'identifiant dans ledit autre paquet. 

1 1 . Procede selon la revendication 1 0, caracterise en ce que I'identifiant (14) est 
contenu dans I'en-tete (1 1) au protocole de la couche OSI 3 dudit autre 
paquet (15a ; 15b), I'etape b) comprenant la lecture par le nceud de 
I'identifiant dans I'en-tete au protocole de la couche OSI 3 dudit autre 

25 paquet. 



12. 



Procede selon la revendication 10 ou 1 1, caracterise en ce qu'il comprend 
apres I'etape b), une etape de : 
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- envoi par le noeud vers une base de donnees (21) de I'identifiant (14) et de 
ladite information. 

13. Procede selon la revendication 5 ou 6, caracterise en ce qu'il comprend 
apres I'etape a) et avant I'etape b), une etape de : 

5 - interrogation par !e noeud d'une base de donnees (21 ) avec I'identifiant 

(14). 

14. Paquet de donnees (10) pour un reseau de communication par paquets, 
comprenant une information independante des protocoles des couches OSI 
5 a 7 du paquet et concernant au moins I'une des caracteristiques 

1 0 suivantes : 

- le type de donnees transportees dans le paquet, 

- la source d'emission des donnees transportees dans le paquet autre que 
I'adresse reseau de la source d'emission du paquet, et 

- le destinataire des donnees transportees dans le paquet autre que 
1 5 I'adresse reseau de la source d'emission du paquet. 

1 5. Paquet de donnees selon la revendication 14, caracterise en ce que ladite 
information est independante des protocoles des couches OSI 4 a 7 du 
paquet. 

1 6. Paquet de donnees selon la revendication 1 4 ou 1 5, caracterise en ce que 
20 ladite information est contenue dans I'en-tete (1 1) au protocole de la couche 

OSI 3 du paquet. 

1 7. Paquet de donnees selon la revendication 1 6, caracterise en ce que le 
paquet est au protocole IP, ladite information etant contenue dans I'en-tete 
IP. 

25 1 8. Generateur de paquets tels que definis par Tune quelconque des 
revendications 14 a 17. 
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